\section{Architecture}

In this section we explain how our program is structured and argue for our
design. We approach this by explaining our implementation of the Model-View-Controller architecture, the delegation of
responsibility to the different classes and a visualization of the flow involved when initializing the program and
performing a search.

\subsection{Model-View-Controller}
Our design is based on implementing the Model-View-Controller (MVC) pattern. A
key principle here is to separate the domain layer (model) from the user interface (UI) layer (view) \cite{Larman}: 209. Thus, the application logic 
is encapsulated in the model, which, among many other advantages, helps the model focus on (and only on) domain 
activities, enables coherent work on different parts of the program
\cite{Larman}: 209. 
\begin{figure}
\begin{center}
%UML: Package diagram
\includegraphics[scale=0.6]{../architecture/package.pdf}
\end{center}
\caption{Diagram of the packages in the project\label{package}} 
\end{figure}
\\
\\
Our implementation of the MVC pattern is reflected in the package structure as
shown in figure \ref{package}. The package \texttt{view} contains three
different views representing the UI layer of our program. The package
\texttt{utilityClasses} contains classes for writing to a file and recording
time - both used in benchmarking, see section \ref{benchmark}. The package
\texttt{driver} is where our program's main method is located, the arguments are read 
and the instantiation of the program takes place. This is visualized in a
sequence diagram of the initialization (using the \texttt{SwingView} and
\texttt{NestedLinkedListSearcher}) in Appendix F. The package \texttt{controller}
contains the controller of our program, which mediates between the view and the
model, which is visualized in Appendix G depicting a
sequence diagram of a search (using the \texttt{SwingView} and
\texttt{NestedLinkedListSearcher}). The separation between view and model is
obtained exactly by the controller's mediation, which eliminates the need for either of the two to know each other. The package \texttt{model} contains the search logic and handles the creation/maintenance of the different data structures. The classes constituting
the actual data structures are located here as well as in the sub-package of the
related searchers, respectively. It is within the \texttt{model} this project's
the mandatory assignments are solved, which is why the classes, relations
and activities within this package are emphasized throughout this report.
\\
\\
The package structure within the model is structured around the different
searchers encapsulating the search logic of our program within the package
\texttt{model.searchers}. The simplest of the searchers, the linked list
searcher, is rooted in \texttt{model.searchers.linkedListSearcher} together with
its data structure. The nested linked list searcher and the related
data structure are located in
\texttt{model.searchers.advancedSearchers.nestedLinkedListSearcher}, while the
hash table searchers are found in
\texttt{model.searchers.advancedSearchers.hashTableSearchers}. The handling of Boolean
operators is delegated to classes located in the package
\texttt{model.parseTree}.
\\
\\
When initialized, an object implementing the interface
\texttt{ISearcher} constitutes the (only) part of the model that is communicating directly 
with the rest of the program (that is, through the controller). 
\texttt{ISearcher} thereby defines the possible interfacing with the model.

\subsection{Assigning Responsibilities}\label{arc_resp}
The MVC pattern actually deals with responsibility assignment by delegating the
application logic to the model, the UI layer to the view and the mediation between the 
two to the controller. In the following we explain and argue for important choices made in regard to delegating responsibilities within our model. We do so with base in the 
collection of General Responsibility Assignment Software Patterns (GRASP)
\cite{Larman}: 17.9. We now shortly draw forward key patterns within the GRASP collection needed in the argumentation 
for our design.
\\
\\
According to the creator pattern, the responsibility for creating an object should be delegated to the class that 
contains it, closely uses it, or has the necessary initialization data \cite{Larman}: 291-292.
\\
\\
The information expert pattern says that responsibilities in general should be assigned to classes that have the 
information to fulfil that responsibility \cite{Larman}: 294-298.
\\
\\
The high coherence advocates for a strong relationship between the doing and knowing responsibilities a class is 
delegated and in general a clear focus among these responsibilities \cite{Larman}: 314-318.
\\
\\
The low coupling pattern articulates the goal of reducing (unnecessary) coupling of classes. This applies to both 
knowing and doing responsibilities, and is often obtained by implementing other GRASP patterns \cite{Larman}: 299-302.
\\
\\
The polymorphism pattern deals with the problem of different types (classes) handling related operations differently. 
It suggests a solution in which the responsibility for the operation is assigned
polymorphic - often by letting the classes implement a common interface \cite{Larman}: 414.
\\
\\
With basis in the above theory and terminology, we will explain and argue for our design choices in the next section.

\subsubsection{Delegation of Responsibilities in Our Program}
Due to space limitations, we will limit this discussion to the most important
design choices (the implementation should generally reflect the same design
principles). This will be structured around key issues considered while
designing our program. For the sake of overview we have included a stripped down
diagram of the relationships between the classes within our model. See Appendix
A for a full class diagram of data structures and searchers.

\begin{figure}
\begin{center}
\includegraphics[scale=0.6]{../architecture/Searchersdiagram.pdf}
\end{center}
\caption{Shows a diagram of the Classes in the project\label{Class}}  
\end{figure} 

\subsubsection{Relationship Between Searching and the Data Structures}
To obtain
high coherence, we decided to split the search logic from the actual data
structure. The responsibility for the search logic is delegated to the different
searcher-classes together with the (coherent) responsibility for creating,
knowing and maintaining the data structures. They should own/know about the data
structures because they need this in order to performing a search. The
delegation of the responsibility for creating the data structures can be understood 
from the creator pattern in that the searchers both contains them, closely uses them, and has the necessary initialization data.
\\
\\
In the hash table-based searchers, search logic and data structures are not
totally separated, see section \ref{hash_imp}. Because of
that, we considered to consistently delegate the search responsibility to all
the data structures, but we discarded this design to avoid unfocused classes
doing both search logic, keeping and maintaining data and reading in the data
from a file. Another argument for the current design despite the somewhat
compromising pass of the \texttt{get}-method is the gain of a uniform interface
across all searchers. This leads us to the next design consideration.

\subsubsection{Different Implementations of Related
Methods?}
The concrete differences above in the way a search is
performed across the different searcher classes poses a challenge in that we want the ability to interface uniformly 
with the model from the rest of our program 
regardless of the specific type of searcher. To solve this problem, we have implemented the polymorphism pattern 
by both implementing a common interface and an inheritance hierarchy starting from the abstract class GenericSearcher. 
The interface \texttt{ISearcher} facilitates a polymorphic delegation of the
search functionality - regardless of differences in the searcher's concrete implementation. The inheritance structure helps 
realizing this by declaring the abstract method \texttt{formatResult(LinkedList
l)}. Besides, this inheritance structure enables us to eliminate duplicate code.
\\
\\
The rationales for the inheritance structure and common interface of the data
structures (at least the data structures based on lists) are very similar to the
ones explained above.

\subsubsection{Benefits of Our Design}\label{design_benefits}
The achievement of low coupling in our program through a modular architecture -
expecially expressed in the implemented MVC pattern - facilitated the writing of
a second (command-line) view in less than 20 minutes. For the same reasons, it
was relatively easy and fast to write a benchmark view.